【レポート】AWS Summit Tokyo 2017：ゲオを支える DB 基盤の歴史と未来　～Oracle から Amazon Aurora へ～ #AWSSummit

AWS Summit Tokyo 2017

にしざわ

2017.05.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

aws-summit-tokyo-2017-longlogo 2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪品川プリンスホテルアネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『ゲオを支える DB 基盤の歴史と未来　～Oracle から Amazon Aurora へ～』に関する内容をレポートしたいと思います。

(2017/06/16追記：)イベント公式の関連資料及び動画が公開されましたので展開します。

セッション概要

当セッションの登壇者及び概要は以下の通りです。

スピーカー：
神野旬様
株式会社ゲオホールディングス業務システム部ゼネラルマネージャー

セッション概要：
ゲオホールディングスでは、ゲオ、セカンドストリート、ウェアハウス、ゲオモバイル等、約 1700 店舗を運営しています。その事業を支えている DB はどのようになっているのか、今後どうしていくのか、移行時につまずいたところも交えてご紹介します。

以下、セッションレポートです。

比較的オーソドックスな使い方だが、多数のAWSサービスを使っている
EC2は全部で150インスタンスくらい
ネットワーク
- 小さい店舗はインターネットVPN
- 大きな拠点はキャリア網
- USAはインターネット経由で
Azureも利用してマルチクラウドで運用
AWSアカウントは4つ
- 本番
- 本番セキュア
- 2nd STREET USA
- 開発
集計システム
- レンタル実績に応じて、新作・旧作の区分を集計、変更
- Oracle Exadata: 10h -> Redshift: 2.5h(転送、書き戻しは含まない)
監視運用
- 死活
  - Zabbix
  - Slack
  - Twilio
- リソース
  - スケジューラで自動起動/停止
- バックアップ、CPUクレジット監視
  - タグ活用
  - Lambda活用
- ログ保管、検索
  - Slack
  - Lambda -> S3 -> Athena

OracleおよびMS SQL Server複数台をDB Linkで構成していた
- ネットワーク断で同期ができなくなる
- DB連携はテキストを利用するように変更
分散しているDBをOracleバッチ系と、Oracle RACオンライン系に集約した
- 集約しすぎてリソース枯渇
- Exadataにして解決
- それでもOLTPもDWHの併用はきつかった

目的
- Oracle保守切れ
- Exadata側の不具合にも何度か当たった
- スケジュールとしては4〜5ヵ月で移行
ポイント
- FullアクセスをやめてディスクIOを減らしCPUを使用するインデックスチューニングを実施
- 苦手なところは他にオフロード
  - 高負荷バッチ処理をRedshiftに
  - インメモリDBも利用
- EBSは複数の汎用SSDを並べてコストを抑えつつ、スループットを確保
- 今ならDMSも利用可能
EBS構成
- 合計50TB/実容量11TB
  - PIOPSを確保する為に実利用量より多くEBSを用意した
- Oracle ASMでボリュームを分散
- UNDO、TEMPはPIOPSでスループット確保
移行でつまづいたところ
- AWSの各種上限に引っかかった

目的
- 脱Oracle、コストDOWN
- ライセンスも運用コストも
移行スケジュール
- 概ねテストは終わっているが、PostgreSQL互換AuroraはまだGAになっていない
- 来年夏を目処に現在移行中
移行対象は会員情報が格納されたDB
- セキュリティ
  - 操作は全て録画
  - AWS側のIAMで制限
  - MFA
ワークロード
- 小さめのSQLが多く、並列度が高い
- 稀にバッチ系の大きめのSQL
- 4000万件超のデータ
移行候補
- これらを比較検討した
  - EDB Postgres
  - RDS PostgreSQL
  - Aurora MySQL
  - AUrora PostgreSQL
Oracle PostgreSQLの違い
- DB LInk(FDW)は速度があまり出ない
- パーティションはちょっと使いづらい
- PL/SQLの移行が一番大変
- DDLもロールバックできる
- 表現や関数の違い、同じ名前でも意味が違う場合もある
SCT
- DB移行を補助してくれるツール
- スキーマ単位でのSQLで出力して微調整
- シノニムが存在しないため、検索パス指定をしたりした
DMS
- フルーロード、差分転送ができる
- 200GB、テーブル13、データ6.4億件
- 並列度、CommitRate、インスタンスタイプをチューニングして、4日->10hに短縮成功
- インデックスは別で作った方が早いかも
テスト
- テスト環境を作るのが楽
- 本番同等のリクエスト
移行手順
- DMSでダウンタイムを小さくすることができた

良かったこと
- 開発エンジニアがインフラに興味を持つようになった
- ハードにかかるコストを意識増
- サイジング不要、構築しながら調整
- インフラのリードタイム減
- エンジニアのモチベーションUP
- 本番同等のテストが簡単にできる
- オンプレに比べ、故障頻度が下がった(たまたまかも？)
気をつけた方が良いこと
- 最低限のルールは作らないと無法地帯に
- クラウドのメリットは残しつつ
- 何でもタグをつけておく
- RI購入がドキドキする、ちょっとわかりづらい
- AWS都合のEC2再起動が少し手間
- 落ちる前提で作る、必要に応じて冗長化
- 稀にリソース枯渇で起動できないインスタンスタイプがある
- AWS側の障害の場合、待つことしかできない
Exadata->OracleEEonEC2
- シングル構成のため、RACより可用性は下がっているが、実際は停止時間は減っている
- EBS性能を確保する為にコストが想定よりもコストがかかっている
- IOは負けるが、チューニングや他サービスとの組み合わせで改善
OracleEE->AuroraPostgreSQL互換
- Auroraはとにかくメリットが多い
- DBA不要